Tagged “web stuff”

1. From CMS to Static Site

   18 Aug 2019 web stuff

   For the past few years I've been using wordpress on this website.
   I wanted to use wordpress for something where I can experiment freely and learn the most popular CMS.
   Wordpress is fantastic piece of open source software, but for this site it was pretty overkill.
   To get most out of wordpress, Automatic provides pretty nice plugins (Jetpack, WP Super Cache, WooCommerce etc.) and nice mobile app, but resorting to wp plugins when my needs are simple added some overhead.
   Developing my the wordpress theme requires running wordpress locally.
   When working with client-side stuff, I felt like running wp was too much.
   In this site the content is sometimes coupled with the the presentation, in wordpress it means that you need to develop the theme but create the content as you normally do with wp (requires syncing dev env db's to production).
   For these reasons I figured static web site generator would suit my needs better, since after all I have been pretty lazy with my blogging, so this site has been quite static already.

   Previously I have worked with Jekyll when using github pages and it was OK.
   But I preferred nodejs as I have more experience with js than ruby.
   I saw many people from front-end community recommend eleventy and it seemed quite nice.
   I suffer from bundlephobia so I decided to look at 11ty's dependencies, and this was the only thing about eleventy that didn't quite convince me.
   But afterall 11ty produces static HTML with various templating options, while providing development time "nice to have" features (browser-sync etc.), so multiple dependencies can be expected. In addition tiny modules are the norm in npm land, which has lead to issues (security and maintainability-wise), but people have learned and the intent to "do one thing and do it well" has proven itself (see: Isaac Z. Schlueter - Unix Philosophy and Node.js).
   Well at least I am moving away from PHP to static HTML, which will remain portable ¯_(ツ)_/¯.

   Developing the site now is much simpler, layout and content go hand-in-hand and they are both under version control, no need for separate backups.
   The content is written with markdown, which was already the case, but in WP it required Jetpack.
   My theme's Sass stylesheets were pretty much transferable, eventhough my markup slightly changed which was nice.

   The site's performance is un-surprisingly much better as well according to lighthouse.

   While I was at it I moved hosting of this site to Netlifly.
   brb stuck in JAMstack now 🤙.

2. Vue's Reactivity By Example

   06 Feb 2018 web stuff

   We wanted to create a landing page for our association; kolmekolmesata, so I created one.
   You might like the site if you enjoy seeing bunch of SVG polygons appear and disappear over and over again, but you might not like it if you’re after information about our association, well you can’t please them all.
   In this brief post I’ll explain what I learned during the process.

   The site was created with Vue.js using SVG, in this post I’ll briefly explain how the Vue’s reactivity system makes it so easy to declare a view like this:

   <template v-for="x in xAmnt">
       <template v-for="y in yAmnt">
           <cube
           :height="cubeHeight"
           :width="cubeWidth"
           :x="getXCoord(x, y, cubeWidth, cubeHeight)"
           :y="getYCoord(x, y, cubeWidth, cubeHeight)"
           :toggled="isToggled(x, y)"
           :key="x + y * xAmnt"
           @mouseover.native="mouseOverCube"
           />
       </template>
   </template>

   and as a result see something like this:

   

   How it works; so the template above declaratively defines the entire view. The value isToggled returns for each coordinate varies over time. So one might wonder how does Vue track the properties used in .isToggled()?

   Well Vue’s documentation does no exceptions here, it is very good also on this subject.
   The gist is that during the initializing of your component, Vue walks through your data object and defines getters and setters for each property.
   Each component has a watcher, the watcher defines whether a property’s getter has been run during the execution of the template (or render method), if so the property is marked as “touched”. The watcher is also used when a setter is called for the touched property, the watcher then re-trigger the rendering of the component.

   So in our case on the first render Vue notices that rendering these cubes uses a distanceToSweetSpot property, as every cube’s coordinate is compared to it.
   In our app this distance is changed simply by assigning a new value to it every interval. Vue has defined the setter for the distanceToSweetSpot property with Object.defineProperty, the setter is executed every interval. When executing the setter it notifies the watcher that we’d want to re-trigger the templating function.

   If you’re interested on the details of the site, feel free to read the source from the repository in github.

See all tags.